聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

Claude 官方文件在「Choosing a model」這一節，開頭第一句是這樣寫的：

If you're unsure which model to use, start with Claude Opus 5.

（如果你不確定該用哪個模型，從 Claude Opus 5 開始。）

第一次讀到這句，我的反應是：憑什麼是它？

Opus 5 既不是最便宜的（Haiku 4.5 只要它的五分之一），也不是最強的（Fable 5 在它上面）。四個選項裡，官方挑了排第二的那個當預設答案。

如果是我來寫這份文件，我大概會寫「從最便宜的開始，不夠用再往上加」——聽起來多合理啊，符合直覺、符合節儉、符合我們寫程式時「先求有再求好」的習慣。

但官方沒這樣寫。而且我後來發現，這不是隨口給的懶人包，它背後有一套挺嚴謹的推理。更有趣的是，同一套推理也出現在官方對 effort 參數的建議裡——兩個看起來不相干的設定，用的是完全相同的方法論。

今天我們把這套推理拆開。拆完之後你會發現，它不只回答「選哪個模型」，它其實回答的是一個更大的問題：面對一個你還不了解的任務，你該從哪裡起步？

本篇引用的官方建議於 2026 年 8 月查證，來源為 Models overview 與 Effort 兩份文件。

目錄

一、先看完整的原文，有個常被漏掉的但書

那句話其實還有後半段：

If you're unsure which model to use, start with Claude Opus 5 for complex agentic coding and enterprise work. For workloads that need the highest available capability, use Claude Fable 5.

兩個關鍵限定詞：

① 「for complex agentic coding and enterprise work」

這個建議是有適用範圍的。它針對的是複雜的代理式編碼與企業工作——不是「你拿 Claude 做任何事都該用 Opus 5」。如果你的任務是把五千筆評論分成正負面（Day 1 那個例子），這句話管不到你。

② 「start with」——是「開始」，不是「就用」

這是最多人漏掉的兩個字。官方沒說「用 Opus 5」，它說「從 Opus 5 開始」。

一個起點，隱含的是「之後會移動」。往哪移動？這是本篇後半的重點。

二、為什麼不從最便宜的開始？

先處理那個最直覺的反對意見：幹嘛不從 Haiku 4.5 開始，不夠用再往上加？

這個策略叫「由下往上」（bottom-up），聽起來很省，但它有一個結構性的缺陷。

想像你在調一台老車的引擎。你聽到引擎有雜音，於是開始調——調了化油器，好像好一點；調了火星塞，好像又好一點。折騰兩小時之後，你還是不確定：這台車現在是「修好了」，還是「只是雜音變小但問題還在」？

因為你從來沒聽過它健康時該有的聲音。

由下往上選模型就是這樣。你用 Haiku 4.5 跑，結果不理想。這時候你面對一個無法回答的問題：

是模型能力不足，還是我的 prompt 寫得不好？

你沒有參考點。於是你開始改 prompt——改了十版，效果時好時壞。你以為自己在做 prompt engineering，其實你在拿一個能力不足的模型做對照組實驗，而且沒有對照組。

由上往下（top-down）則相反。 你先用能力充足的模型跑一次，這一次的結果就是你的基準線：

• 如果 Opus 5 跑出來也不好 → 問題不在模型，是你的 prompt、你的資料、或你的任務定義有問題。往下換更便宜的模型只會更糟，先回頭修 prompt。
• 如果 Opus 5 跑得很好 → 你知道這個任務是做得成的，而且你手上有一份「正確答案長什麼樣」的樣本。接下來往下降級，你有東西可以比對。

這就是為什麼起手點很重要。起手點不只是一個選擇，它是你後續所有判斷的參考座標。 從一個能力不足的地方起步，你會分不清失敗是誰造成的——而分不清原因的優化，全部都是瞎猜。

三、那為什麼不從最強的 Fable 5 開始？

反過來的問題也要回答：既然要建立基準線，那用最強的不是更保險？

三個理由：

① 它的定位不是「更好的通用模型」

Day 1 提過，Fable 5 的官方描述是「for long-running agents」——為長時間執行的代理任務而生。它的強項在於跑三十個步驟不走鐘，而不是單次回答比 Opus 5 漂亮多少。

如果你的任務是一問一答，你付了 2 倍的錢，買的是一個你根本不會用到的特長。

② 它的知識反而更舊

這條 Day 1 講過，但值得再提一次，因為它太反直覺了：

最貴的那個，知識比次貴的舊了四個月。用 Fable 5 當基準線，你的基準線可能建立在過時的資訊上。

③ 它更慢

建立基準的階段你會跑很多次實驗。Fable 5 的相對延遲是「較慢」，Opus 5 是「中等」。實驗迭代速度慢一倍，你的開發節奏就慢一倍。

四、真正的方法論：先確認做得對，再往下調到省

現在把整套邏輯串起來。

官方的建議不是「用 Opus 5」，是一套兩階段流程：

階段一：建立基準（先求對）
  用 Opus 5 跑 → 得到「這個任務做得成、而且長這樣」的樣本

階段二：往下探底（再求省）
  換 Sonnet 5 跑 → 拿結果跟基準比 → 品質守得住嗎？
    守得住 → 繼續往下試 Haiku 4.5
    守不住 → 停在 Sonnet 5，或回頭修 prompt 再試

有意思的是，官方在講 effort 參數時，給的是一模一樣的流程：

Start with high, the default, and adjust based on your evals: (...) use low and medium liberally as your primary control for token cost and response time wherever your evals show quality holds.

（從預設的 high 開始，再依你的評測調整：(...) 只要你的評測顯示品質守得住，就大方地用 low 和 medium 來控制成本與回應時間。）

同一套：從足夠高的地方起步，然後在有證據的前提下往下降。

官方甚至補了一句很值得玩味的提醒：

If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them.

（如果你把舊模型的 effort 設定沿用過來，請重新跑一次評測，不要直接沿用。）

換句話說——連你自己上一次調好的設定，都不算證據。 模型換了，一切重測。

我寫這系列時把書名訂成「用得對，也用得省」，順序是刻意的。今天查完官方文件我才發現，這個順序跟官方的方法論剛好一致：先確認做得對，再往下調到省。 反過來做——先追求省，再想辦法讓它變對——那不是優化，那是在猜。

五、「evals」這個字，是整套流程的關鍵

上面引文裡反覆出現一個詞：evals（評測）。

「wherever your evals show quality holds」——只要你的評測顯示品質守得住。

這句話的重量在於：降級的許可證是評測給的，不是感覺給的。

我知道你在想什麼：「我哪有時間建評測系統？」

但 evals 不一定要是一套完整的框架。最小可行的版本可以很土：

❌ Before：憑感覺降級

# 「Opus 5 跑起來還不錯，但好貴喔，換 Haiku 試試」
model = "claude-haiku-4-5"
# ...跑了幾次，看起來還可以，就上線了

✅ After：留一份基準，比對之後再決定

# 1. 準備 20 個有代表性的輸入（含 3~5 個你知道很難的邊界案例）
TEST_CASES = load_cases("cases.json")

# 2. 先用 Opus 5 跑一遍，把結果存起來當基準
baseline = {c["id"]: run(c, model="claude-opus-5") for c in TEST_CASES}

# 3. 換模型跑，逐案比對
for c in TEST_CASES:
    result = run(c, model="claude-haiku-4-5")
    if not matches(result, baseline[c["id"]]):
        print(f"降級後不一致：{c['id']}")

差別不在程式碼複雜度——After 版本也才十行。差別在你有沒有留下基準。

而且注意第一步那句「含 3~5 個你知道很難的邊界案例」。這是整件事最關鍵的地方：只用簡單案例測，任何模型都會過關。 你會很開心地降到 Haiku 4.5，然後在正式環境遇到第一個複雜輸入時翻車。

評測的價值不在證明模型可以，而在找出它從哪裡開始不行。

二十個案例、一個 JSON 檔、十行程式碼。這就夠你拿到降級的許可證了。

六、什麼時候可以跳過這套流程？

最後說點實在的。這套「先建基準再降級」的流程有成本，不是每次都值得。

我的判斷方式是問一句：這個任務會跑幾次？

換句話說：優化的價值跟呼叫次數成正比。 跑一次的東西，最貴的模型就是最便宜的選擇，因為你的時間比 token 貴。

本篇自我挑戰

• 今日挑戰：挑一個你正在用 Claude 做的任務，寫下 20 個測試輸入存成一個檔案。不用寫任何程式，就是把輸入列出來——但其中要有 3 到 5 個你知道很難的（最長的、最模糊的、格式最亂的那種）。

  光是「刻意去想哪些案例會很難」這個動作，就會讓你對這個任務的理解深一階。這份清單之後 Day 27 講模型分流時還會用到。

• 反思：「先求有再求好」是我們寫程式時的預設習慣，但在選模型這件事上，官方建議的是反過來的「先求好再求省」。你覺得這兩種思維的分界在哪裡？我的想法是：當「不好」的代價可以被立刻看見時，先求有是對的；當「不好」會悄悄混進結果裡而你不會發現時，就必須先求好。 你同意嗎？

總結

官方那句「從 Opus 5 開始」，拆開來看不是一個推薦，而是一套方法論。

不從最便宜的開始，因為失敗時你分不清是模型不行還是 prompt 不行——沒有基準線的優化只是瞎猜。不從最強的開始，因為 Fable 5 的特長是長時間代理任務，你多付的錢買不到單次品質，而且它的知識反而更舊、速度更慢。

真正的流程是兩階段：先用足夠好的模型建立基準，確認任務做得成；再依評測結果一階一階往下降。 而降級的許可證是評測給的，不是感覺給的——最小版本只要二十個案例和十行程式碼，關鍵是裡面必須有你知道很難的邊界案例。

最後別忘了那句但書：優化的價值跟呼叫次數成正比。 跑一次的東西，別優化。

本日關鍵字回顧

• 由上往下選模型（Top-down）：先用能力充足的模型建立基準，再逐階降級。官方建議的預設起手是 Opus 5。
• 基準線（Baseline）：一份「這個任務做得成、且結果長這樣」的參考樣本，是後續所有降級判斷的座標。
• Evals（評測）：降級的依據。最小可行版本為 20 個涵蓋邊界案例的測試輸入加上逐案比對。
• 邊界案例（Edge case）：最長、最模糊、格式最亂的輸入。評測的價值在於找出模型從哪裡開始失效。
• start with 的語意：官方用詞是「從……開始」而非「使用」，隱含後續會依評測移動。

明天我們往下走一階，去看那個最容易被當成次等品的模型。Claude Haiku 4.5 是四個裡面唯一的「上個世代」，但它有一件事做得比誰都好——而且用對的話，它能幫你把成本砍到五分之一。

Day 4，我們談便宜模型的正確用法。